This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
Re: I have tried to eliminate variables under my control. ~Karl Eknuplopoopsi 4.Jun.03 07:59 AM a Web browser Domino Server 6.0.1Windows 2000
And there's the rub right there. The problem with broken path MTU discovery is that the one element that could fix it is _not_ under your control.
Scenario: Remote site connects to you to deliver large email (probably has an attachment).
Both you and remote site have some kind of broadband connection and the mail hosts connect to the firewall/router via an ethernet device. These hosts will most likely negotiate an initial MTU size that is quite large.
Remote host now sends an large packet with "do not fragment" (don't ask me why a mail server would do this but I know some do). Somewhere in transit a router says "need to fragment" (i.e. this packet is too big for me). Because the packet is marked do not fragment, this router responds to the sending host with an ICMP message "destination unreachable". This should tell the sending host to try again with a smaller packet, but only if it actually received the ICMP message.
Sending (remote) host is behind a firewall and the security admin there is paranoid about ICMP and has it blocked at the firewall.
Remote host never sees the ICMP destination unreachable message and the whole conversation stops.
Obviously the one variable that you cannot eliminate is the policy on the remote firewall. Until you can do this, the whole MTU thing must remain an untested hypothesis, but whatever the issue, it does look like a problem with the IP stack rather than necessarily anything to do with the Domino SMTP listener.
Return to top
. . . . . . . . . . . . Re: I have tried to eliminate varia... (~Karl Eknuplopo... 4.Jun.03) 
Print this page
